Accessible JavaScript

James Nurthen

Oracle

History

1194.22(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]

Myths

• JavaScript isn't accessible
• Screen Readers don't support JavaScript
• People turn JavaScript off

The Reality

• JavaScript can be made accessible
• JavaScript can enhance accessibility
• WebAIM Survey - 98.4% of users have JavaScript enabled
• The few users who turn off JavaScript do so for reasons other than accessibility
• JavaScript is supported by all modern browsers and AT
• Every web site can decide if they want to support users who have disabled JavaScript

Common Problems

• Modified Widget Behaviour
• Mouse-only interactions
• Focus getting lost
• Focus moving in an unexpected manner
• What just happened?

Relevant WCAG 2 Guidelines

• 2.1.1 Keyboard
• 2.1.2 Keyboard Trap
• 2.4.3 Focus Order
• 3.2.1 On Focus
• 3.2.2 On Input
• 3.3.1 Error Identification
• 4.1.2 Name, Role, Value

WCAG 2 Principles

• P - Perceivable
  This means that users must be able to perceive the information being presented
• O - Operable
  This means that users must be able to operate the interface
• U - Understandable
  This means that users must be able to understand the information as well as the operation of the user interface
• R - Robust
  This means that users must be able to access the content as technologies advance

Perceivable

• Nothing Special Here!
• Content added (or removed) follows normal accessibility rules
  • Added images have correct ALTernative text
  • Form fields properly labeled
• Follow all the usual accessibility rules however the content is added to the page

Operable

• Triggering Events
• Secondary Events
• Time Limits
• Controlling Moving Information
• Hiding/Showing Content
• Focus Order
• Focus Visibility

Operable - Triggering Events (2.1.1)

• Historically WCAG1 stated to always use redundant event handlers
  • onkeypress + onclick
  • A BAD thing. Pressing Enter on a button or link will fire both!
• click event fires "When a mousedown and mouseup event occur on the same element OR an element is activated by the keyboard."
• DOMActivate event deprecated in DOM3 Events - replaced by click event

Operable - Secondary Events (2.1.1)

• Functionality MUST be device independent
• Events need not be device independent
  • Sometimes events are used which are not the only way of performing an action
  • Example - ondoubleclick event which opens the item. The same functionality is available via a button.
  • Duplicate ways to launch functionality must be documented, supported etc.

Operable - Time Limits (2.2.1)

• Often the only way to meet this is scripting
• Banking applications etc. where a time limit is necessary for Security (or Server performance) reasons
  • Generally reset the timer every server interaction
  • If timer expires send user a dialog asking if need more time
  • If user doesn't reply in a certain amount of time the user will need to restart session

Operable - Moving Information(2.2.2)

• Avoid Auto-play
• If it does auto-start make sure it can be stopped

Operable - Hiding/Showing content(2.4.1)

• Expandable regions are a way of meeting "Bypass Blocks"
• Come back to this later...

Operable - Focus Order(2.4.3)

• OLD:

  "Never move focus"

• NEW:

  "You MUST move focus when appropriate"
  • Lightboxes
  • Dialogs
  • "Add a record" button
  • "Delete this row" button

Operable - Focus Order - Tips

• tabindex
  • 0 - add to tab order
  • -1 - make focusable programatically
• Move focus to where you want reading to start - not just the first "control".
• Insert new content in the right place in the document
• Make sure you don't remove the element which is currently focused. If you do move the focus to the "right" place.

Operable - Focus Order - Complex Widgets

• Roving tabindex
  • Set the tabindex=-1 on the child element to allow it to be focusable
  • Set focus();
• aria-activedescendant
  • Set aria-activedescendant to the child component
• In both cases
  • Make sure there is a visible focus!
  • AT gets focus change event from browser

Operable - Focus Visibility(2.4.7)

• Mostly with CSS.
  • CSS Selectors useful here!
• Complex Widgets need javascript to modify a class

Understandable

• On Focus
• On Input
• Errors
• Notification

Understandable -
On Focus (3.2.1), On Input(3.2.2)

• Some Events must not cause a change of context

  major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. Changes in context include changes of:

  1. user agent;
  2. viewport;
  3. focus;
  4. content that changes the meaning of the Web page.

  Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).

Understandable - On Focus , On Input

• Can still use these JavaScript events if
  • The code doesn't cause a change of context (i.e. XMLHttpRequest updating some other content)
  • The content updated is not a change of context
• This absolutely does not prohib certain events being used - only events that cause a change of context
• SELECT elements
  • The Problem: onChange fires when navigating through the list using up/down
  • Solution 1: Use onBlur & onChange to fire the event once focus leaves the element, move focus to the right place after form submit.
  • Solution 2: use a "go" button after the list
  • Solution 3: use Ajax to fire the event - make sure focus doesn't move

Understandable - Errors(3.3.1)

• Client-Side Validation
• Server-side Validation
• How to notify the user
  • aria-alertdialog
  • aria-dialog
  • aria-required
  • aria-invalid
  • Move focus to text with the error message

Understandable - Errors

• Better to Prevent Errors
  

  <label for="LastName">
   <span id="lastNameLabel">Last Name</span>
   <img alt="required" src="required.gif">
  </label>
  <input type="text" id="LastName"
  aria-required="true" aria-labelledby="lastNameLabel"> 
  	
  Last Name *
  	

Understandable - Notification

• Not always necessary
  • Updating elements in the page which follow the control (WCAG2)
  • When the behaviour is "obvious"
• ARIA live regions (aria-live="polite", aria-live="assertive")
  • Before using live regions look for more specific roles
  • Dialog
  • Log
  • Status
• aria-controls
  • Not yet accessibility supported

Robust (4.1.2)

• Making "New" Controls
• Changing the purpose of existing controls
• Use ARIA roles
• Follow Best Practices for keyboard interaction
  
  OR
• Use libraries which are ARIA enabled

Accessible JavaScript

• Many Oracle products include accessible JavaScript
  • Oracle Fusion Applications
  • Peoplesoft
  • Oracle E-Business Suite
  • Oracle ADF Faces
  • Oracle Application Express

Summary

• Ensure Controls behave correctly or modified behaviour is explained
• How is it triggered (events)
• Controlling Focus
• Notifying the user about the results
• Ensure elements inserted / removed are properly labeled etc.